Навигиране в промяната: Стратегии за миграция на JavaScript API на Manifest V3 за разширения за браузъри

Пейзажът на разработката на разширения за браузъри непрекъснато се развива. Една от най-значимите промени през последните години е въвеждането на Manifest V3 (MV3). Тази актуализация, водена от Google Chrome, но оказваща влияние върху други браузъри, базирани на Chromium, и все повече върху Firefox, има за цел да подобри сигурността, поверителността и производителността за потребителите по целия свят. За разработчиците този преход налага задълбочено разбиране на промените, особено по отношение на JavaScript API. Това изчерпателно ръководство ще ви даде знанията и стратегиите за ефективно мигриране на съществуващите разширения Manifest V2 към MV3, като гарантира, че вашите творения продължават да функционират и процъфтяват в новата среда.

Разбиране на основните промени в Manifest V3

Manifest V3 представлява фундаментално преосмисляне на начина, по който работят разширенията за браузъри. Основните двигатели зад тези промени са:

• Подобрена сигурност: MV3 въвежда по-строги политики за сигурност, ограничаващи видовете кодови разширения, които могат да изпълняват, и как могат да взаимодействат с уеб страници.
• Подобрена поверителност: Новият модел набляга на поверителността на потребителите, като ограничава достъпа до определени чувствителни API и насърчава по-прозрачна обработка на данни.
• По-добра производителност: Отдалечавайки се от някои по-стари архитектури, MV3 има за цел да намали влиянието на разширенията върху скоростта на браузъра и потреблението на ресурси.

Най-въздействащите промени от гледна точка на JavaScript API се въртят около:

• Service Workers заменят Background Pages: Моделът на постоянна фонова страница се заменя от service workers, задвижвани от събития. Това означава, че вашата фонова логика ще се изпълнява само когато е необходимо, което може значително да подобри производителността, но изисква различен подход към управлението на състоянието и обработката на събития.
• Модификация на Web Request API: Мощният `chrome.webRequest` API, широко използван за прихващане на мрежови заявки, е значително ограничен в MV3. Той се заменя с `declarativeNetRequest` API, който предлага по-запазващ поверителността и производителен, макар и по-малко гъвкав подход.
• Промени в изпълнението на Content Script: Въпреки че content scripts остават, техният контекст на изпълнение и възможности са усъвършенствани.
• Премахване на `eval()` и `new Function()`: От съображения за сигурност, `eval()` и `new Function()` вече не са разрешени в кода на разширения.

Ключови миграции и стратегии на JavaScript API

Нека се потопим в спецификата на мигрирането на ключови JavaScript API и да проучим ефективни стратегии за всеки от тях.

1. Миграция от Background Script към Service Worker

Това е може би най-фундаменталната промяна. Разширенията Manifest V2 често разчитат на постоянни фонови страници, които винаги са работили. Manifest V3 въвежда service workers, които се задвижват от събития и работят само когато бъдат задействани от събитие (напр. инсталиране на разширение, стартиране на браузър или съобщение от content script).

Защо тази промяна?

Постоянните фонови страници могат да консумират значителни ресурси, особено когато много разширения са активни. Service workers предлагат по-ефективен модел, гарантиращ, че логиката на разширението се изпълнява само когато е необходимо, което води до по-бързо стартиране на браузъра и намалено използване на паметта.

Стратегии за миграция:

• Логика, задвижвана от събития: Преструктурирайте вашата фонова логика, за да бъде задвижвана от събития. Вместо да приемате, че вашият фонов скрипт винаги е наличен, слушайте за конкретни събития. Основната входна точка за вашия service worker обикновено ще бъде събитието `install`, където можете да настроите слушатели и да инициализирате вашето разширение.
• Предаване на съобщения: Тъй като service workers не винаги са активни, ще трябва да разчитате в голяма степен на асинхронното предаване на съобщения между различни части на вашето разширение (напр. content scripts, popups, options pages) и service worker. Използвайте `chrome.runtime.sendMessage()` и `chrome.runtime.onMessage()` за комуникация. Уверете се, че вашите обработчици на съобщения са стабилни и могат да обработват съобщения, дори ако service worker трябва да бъде активиран.
• Управление на състоянието: Постоянните фонови страници могат да поддържат глобално състояние в паметта. При service workers това състояние може да бъде загубено, когато работникът бъде прекратен. Използвайте chrome.storage (local или sync), за да запазите състоянието, което трябва да оцелее при прекратяване на service worker.
• Осъзнаване на жизнения цикъл: Разберете жизнения цикъл на service worker. Той може да бъде активиран, деактивиран и рестартиран. Вашият код трябва грациозно да обработва тези преходи. Например, винаги регистрирайте повторно слушатели на събития при активиране.
• Пример:

  Manifest V2 (background.js):

              chrome.runtime.onInstalled.addListener(() => {
    console.log('Extension installed. Setting up listeners...');
    chrome.alarms.create('myAlarm', { periodInMinutes: 1 });
  });
  
  chrome.alarms.onAlarm.addListener((alarm) => {
    if (alarm.name === 'myAlarm') {
      console.log('Alarm triggered!');
      // Perform some background task
    }
  });
              
  
                
                  Copy
                
              
            

  Manifest V3 (service-worker.js):

              // Service worker installation
  chrome.runtime.onInstalled.addListener(() => {
    console.log('Extension installed. Setting up alarms...');
    chrome.alarms.create('myAlarm', { periodInMinutes: 1 });
  });
  
  // Event listener for alarms
  chrome.alarms.onAlarm.addListener((alarm) => {
    if (alarm.name === 'myAlarm') {
      console.log('Alarm triggered!');
      // Perform some background task
      // Note: If the service worker was terminated, it will be woken up for this event.
    }
  });
  
  // Optional: Handle messages from other parts of the extension
  chrome.runtime.onMessage.addListener((request, sender, sendResponse) => {
    if (request.action === 'getData') {
      // Simulate fetching data
      sendResponse({ data: 'Some data from service worker' });
    }
    return true; // Keep the message channel open for async response
  });
              
  
                
                  Copy
                
              
            

2. Замяна на `chrome.webRequest` с `declarativeNetRequest`

`chrome.webRequest` API предлагаше обширни възможности за прихващане, блокиране, модифициране и пренасочване на мрежови заявки. В Manifest V3 неговата мощност е значително намалена от съображения за сигурност и поверителност. Основната замяна е `declarativeNetRequest` API.

Защо тази промяна?

`webRequest` API позволяваше на разширенията да инспектират и модифицират всяка мрежова заявка, направена от браузъра. Това представляваше рискове за поверителността, тъй като разширенията потенциално могат да регистрират чувствителни потребителски данни. Той също така имаше последици за производителността, тъй като JavaScript прихващането на всяка заявка може да бъде бавно. `declarativeNetRequest` премества логиката за прихващане в собствения мрежов стек на браузъра, което е по-производително и запазващо поверителността, защото разширението не вижда директно детайлите на заявката, освен ако не е изрично разрешено.

Стратегии за миграция:

• Разбиране на декларативните правила: Вместо императивен код, `declarativeNetRequest` използва декларативен подход. Вие дефинирате набор от правила (JSON обекти), които указват какви действия да се предприемат върху съвпадащи мрежови заявки (напр. блокиране, пренасочване, модифициране на хедъри).
• Дефиниране на правила: Правилата указват условия (напр. URL шаблони, типове ресурси, домейни) и действия. Ще трябва да преведете вашата `webRequest` логика за блокиране или пренасочване в тези набори от правила.
• Ограничения на правилата: Имайте предвид ограниченията за броя на правилата и наборите от правила, които можете да регистрирате. За сложни сценарии на филтриране може да се наложи динамично да актуализирате наборите от правила.
• Без динамична модификация: За разлика от `webRequest`, `declarativeNetRequest` не позволява динамична модификация на телата или хедърите на заявки по същия начин. Ако основната функционалност на вашето разширение разчита на дълбока модификация на заявката, може да се наложи да преоцените неговия дизайн или да проучите алтернативни подходи.
• Блокиране срещу пренасочване: Блокирането на заявки е лесно. За пренасочване ще използвате действието `redirect`, указвайки нов URL адрес.
• Манипулиране на хедъри: MV3 има ограничения върху модифицирането на хедърите на заявки. Можете да добавяте или премахвате конкретни хедъри, използвайки `requestHeaders` и `responseHeaders` в `declarativeNetRequest`, но сложни трансформации не се поддържат.
• Съображения за производителност: Въпреки че обикновено е по-бързо, управлението на голям брой правила все още може да повлияе на производителността. Оптимизирайте вашите набори от правила за ефективност.
• Пример:

  Manifest V2 (блокиране на изображение):

              chrome.webRequest.onBeforeRequest.addListener(
    function(details) { return { cancel: true }; },
    { urls: ["*://*.example.com/*.png"] },
    ["blocking"]
  );
  
              
  
                
                  Copy
                
              
            

  Manifest V3 (използвайки `declarativeNetRequest`):

  Първо, дефинирайте вашите правила в JSON файл (напр. rules.json):

              [
    {
      "id": 1,
      "priority": 1,
      "action": {"type": "block"},
      "condition": {
        "urlFilter": "*.png",
        "domains": ["example.com"],
        "resourceTypes": ["image"]
      }
    }
  ]
  
              
  
                
                  Copy
                
              
            

  След това, във вашия service worker (или начален скрипт за настройка):

              chrome.runtime.onInstalled.addListener(() => {
    chrome.declarativeNetRequest.updateDynamicRules({
      addRules: [
        {
          "id": 1,
          "priority": 1,
          "action": {"type": "block"},
          "condition": {
            "urlFilter": "*.png",
            "domains": ["example.com"],
            "resourceTypes": ["image"]
          }
        }
      ],
      removeRuleIds: [1] // To remove if it already exists
    });
  });
  
              
  
                
                  Copy
                
              
            

3. Обработка на изпълнението и комуникацията на Content Script

Content scripts са JavaScript файлове, които се изпълняват в контекста на уеб страници. Въпреки че основната им цел остава същата, MV3 усъвършенства начина, по който се изпълняват и взаимодействат с останалата част от разширението.

Ключови промени и стратегии:

• Контексти на изпълнение: Content scripts все още могат да бъдат инжектирани в страници. Въпреки това, възможността за инжектиране на JavaScript директно чрез `chrome.scripting.executeScript` вече е предпочитаният програмен метод за инжектиране на скриптове.
• Асинхронно инжектиране: Когато използвате `chrome.scripting.executeScript`, изпълнението е асинхронно. Уверете се, че вашият код изчаква скрипта да бъде инжектиран и изпълнен, преди да опитате да взаимодействате с неговия DOM или глобален обхват.
• Осъзнаване на `frameId`: Ако вашето разширение взаимодейства с iframes, имайте предвид свойството `frameId`, когато инжектирате скриптове или изпращате съобщения.
• Достъп до DOM: Достъпът до DOM остава основна функция. Въпреки това, имайте предвид потенциала за DOM манипулация да попречи на собствените скриптове на хост страницата.
• Комуникация със Service Worker: Content scripts ще трябва да комуникират със service worker (който заменя фоновата страница) за задачи, които изискват бекенд логиката на разширението. Използвайте `chrome.runtime.sendMessage()` и `chrome.runtime.onMessage()`.
• Пример:

  Инжектиране на скрипт и комуникация (Manifest V3):

              // From your popup or options page
  chrome.scripting.executeScript({
    target: { tabId: YOUR_TAB_ID },
    files: ['content.js']
  }, (results) => {
    if (chrome.runtime.lastError) {
      console.error(chrome.runtime.lastError);
      return;
    }
    console.log('Content script injected:', results);
  
    // Now communicate with the injected content script
    chrome.tabs.sendMessage(YOUR_TAB_ID, {
      action: "processPage"
    }, (response) => {
      if (chrome.runtime.lastError) {
        console.error(chrome.runtime.lastError);
        return;
      }
      console.log('Response from content script:', response);
    });
  });
  
  // In content.js:
  chrome.runtime.onMessage.addListener((request, sender, sendResponse) => {
    if (request.action === "processPage") {
      console.log('Processing page...');
      const pageTitle = document.title;
      // Perform some DOM manipulation or data extraction
      sendResponse({ success: true, title: pageTitle });
    }
    return true; // Keep the channel open for async response
  });
  
              
  
                
                  Copy
                
              
            

4. Елиминиране на `eval()` и `new Function()`

От съображения за сигурност, използването на `eval()` и `new Function()` в рамките на кода на разширение е забранено в Manifest V3. Тези функции позволяват произволно изпълнение на код, което може да бъде значителна уязвимост в сигурността.

Стратегии за миграция:

• Преструктуриране на код: Най-стабилното решение е да преструктурирате вашия код, за да избегнете динамично изпълнение на код. Ако динамично генерирате имена на функции или фрагменти от код, помислете за използване на предварително дефинирани структури, обекти за конфигуриране или шаблонни литерали.
• JSON Parsing: Ако `eval()` е използван за парсване на JSON, преминете към `JSON.parse()`. Това е стандартният и сигурен начин за обработка на JSON данни.
• Object Mapping: Ако `new Function()` е използван за създаване на функции динамично въз основа на вход, проучете използването на обектови карти или switch оператори за картографиране на входовете към предварително дефинирани функции.
• Пример:

  Преди (Manifest V2, НЕ СЕ ПРЕПОРЪЧВА):

              const dynamicFunctionName = 'myDynamicFunc';
  const code = 'console.log("Hello from dynamic function!");';
  
  const dynamicFunc = new Function(code);
  dynamicFunc();
  
  // Or for JSON parsing:
  const jsonString = '{"key": "value"}';
  const jsonData = eval('(' + jsonString + ')'); // Insecure
  
              
  
                
                  Copy
                
              
            

  След (Manifest V3, Secure):

              // For dynamic functions:
  function myDynamicFunc() {
    console.log("Hello from pre-defined function!");
  }
  
  // If you need to call it dynamically based on a string, you can use an object map:
  const availableFunctions = {
    myDynamicFunc: myDynamicFunc
  };
  
  const functionToCall = 'myDynamicFunc';
  if (availableFunctions[functionToCall]) {
    availableFunctions[functionToCall]();
  } else {
    console.error('Function not found');
  }
  
  // For JSON parsing:
  const jsonString = '{"key": "value"}';
  const jsonData = JSON.parse(jsonString); // Secure and standard
  console.log(jsonData.key); // "value"
  
              
  
                
                  Copy
                
              
            

5. Други важни API съображения

Manifest V3 оказва влияние върху няколко други API и е важно да сте наясно с тези промени:

• `chrome.tabs` API: Някои методи в `chrome.tabs` API може да се държат по различен начин, особено по отношение на създаването и управлението на табове. Уверете се, че използвате най-новите препоръчани модели.
• `chrome.storage` API: `chrome.storage` API (local и sync) остава до голяма степен същият и е от съществено значение за запазване на данни при прекратяване на service worker.
• Разрешения: Преоценете разрешенията на вашето разширение. MV3 насърчава да се изискват само необходимите разрешения и предлага по-детайлен контрол.
• Елементи на потребителския интерфейс: Extension popups и options pages остават основните UI елементи. Уверете се, че са актуализирани, за да работят с новата архитектура на service worker.

Инструменти и най-добри практики за миграция

Мигрирането на разширение може да бъде сложен процес. За щастие, има инструменти и най-добри практики, които могат да го направят по-гладък:

• Официална документация: Документацията от доставчиците на браузъри (особено Chrome и Firefox) е вашият основен ресурс. Прочетете внимателно ръководствата за миграция на Manifest V3.
• Инструменти за разработчици на браузъри: Използвайте инструментите за разработчици на вашия целеви браузър. Те предоставят безценни прозрения за грешки, жизнения цикъл на service worker и мрежовата активност.
• Инкрементална миграция: Ако имате голямо разширение, помислете за стратегия за инкрементална миграция. Мигрирайте една функция или API наведнъж, тествайте внимателно и след това преминете към следващата.
• Автоматизирано тестване: Внедрете стабилен пакет за тестване. Автоматизираните тестове са от решаващо значение за улавяне на регресии и гарантиране, че вашето мигрирано разширение се държи както се очаква в различни сценарии.
• Код Linting и анализ: Използвайте linters (като ESLint), конфигурирани за MV3 разработка, за да уловите потенциални проблеми рано.
• Форуми на общността и поддръжка: Ангажирайте се с общностите на разработчиците. Много разработчици са изправени пред подобни предизвикателства и споделянето на опит може да доведе до ефективни решения.
• Помислете за алтернативи за блокирана функционалност: Ако основна функция на вашето разширение разчита на API, който е силно ограничен или премахнат в MV3 (като определени `webRequest` функционалности), проучете алтернативни подходи. Това може да включва използване на браузър API, които все още са налични, използване на евристики от страна на клиента или дори преосмисляне на изпълнението на функцията.

Глобални съображения за Manifest V3

Като разработчици, насочени към глобална аудитория, е важно да обмислите как промените на MV3 могат да повлияят на потребителите в различни региони и контексти:

• Производителност на различни устройства: Ползите от ефективността на service workers са особено полезни за потребители на по-слаби устройства или с по-бавни интернет връзки, преобладаващи на много нововъзникващи пазари.
• Проблеми с поверителността по целия свят: Повишената защита на поверителността в MV3 е в съответствие с нарастващите глобални разпоредби за поверителност на данните (напр. GDPR, CCPA) и очакванията на потребителите. Това може да насърчи по-голямо доверие сред разнообразна потребителска база.
• Съответствие с уеб стандартите: Въпреки че MV3 до голяма степен се ръководи от Chromium, стремежът към по-сигурни и запазващи поверителността модели за разширения на уеб е глобална тенденция. Оставането пред тези промени подготвя вашите разширения за по-широка съвместимост на платформата и бъдещи уеб стандарти.
• Достъпност на документацията: Уверете се, че ресурсите за миграция, на които разчитате, са достъпни и ясно преведени, ако е необходимо. Въпреки че тази публикация е на английски език, разработчиците по целия свят може да потърсят локализирани ресурси.
• Тестване в различни региони: Ако функционалността на вашето разширение зависи от мрежата или може да има фини разлики в потребителския интерфейс в различните локали, уверете се, че вашето тестване обхваща разнообразни географски местоположения и мрежови условия.

Бъдещето на разширенията за браузъри с Manifest V3

Manifest V3 не е просто актуализация; това е значителна стъпка към по-сигурна, поверителна и производителна екосистема за разширения на уеб. Въпреки че миграцията представлява предизвикателства, тя също така предлага възможности на разработчиците да изграждат по-добри и по-отговорни разширения. Като разберете основните промени в API и приемете стратегически подходи за миграция, можете да гарантирате, че вашите разширения за браузъри остават уместни и ценни за потребителите по целия свят.

Прегърнете прехода, използвайте новите възможности и продължете да правите иновации. Бъдещето на разширенията за браузъри е тук и то е изградено върху основата на подобрена сигурност и потребителско доверие.